Capítulo 4 - Ingeniería de requisitos
Los requisitos para un sistema son descripciones de lo que el sistema debe hacer: el servicio que ofrece y las restricciones en su operación. Tales requisitos reflejan las necesidades de los clientes por un sistema que atienda cierto propósito. Al proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se le llama ingeniería de requisitos (IR).
Existen cuatro actividades principales en el proceso de ingeniería de requisitos:
Los requisitos deben redactarse de forma abstracta para que muchos proveedores liciten ofreciendo diferentes maneras de cubrir las necesidades de organización del cliente. Una vez otorgado el contrato, el proveedor tiene que escribir con más detalle una definición del sistema para el cliente, de modo que éste comprenda y valide lo que hará el software. Estos documentos suelen nombrarse documentos de requisitos para el sistema.
Los requisitos del usuario son enunciados, en un lenguaje natural junto con diagramas, acerca de qué servicios esperan los usuarios del sistema, y de las restricciones con las cuales éste debe operar.
Los requisitos del sistema son descripciones más detalladas de las funciones, los servicios y las restricciones operacionales del sistema de software. El documento de requisitos del sistema (llamado en ocasiones especificación funcional) tiene que definir con exactitud lo que se implementará. Puede formar parte del contrato entre el cliente y el desarrollador.
Los requisitos del software son aquellos que se derivan de los requisitos del sistema. ¿Qué queremos que haga el software dentro del distema?
La distinción entre requisitos funcionales y no funcionales puede no ser clara, pues un requisito suele generar o restringir otro. No sólo especifican las características del sistema, sino también las funcionalidades necesarias para que estos servicios se den efectivamente.
Son enunciados acerca de servicios que el sistema debe proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería comportarse o no el sistema en situaciones específicas.
Los requisitos funcionales para un sistema refieren a lo que el sistema debe hacer. Tales requisitos dependen del tipo de software que se esté desarrollando, de los usuarios esperados del software y del enfoque general que adopta la organización cuando se escriben los requisitos.
Por lo general, se escriben de forma abstracta para lectura de los usuarios. Varían desde requisitos generales que cubren lo que tiene que hacer el sistema, hasta requisitos muy específicos que reflejan maneras locales de trabajar o los sistemas existentes de una organización.
Los requisitos funcionales pueden escribirse con diferentes niveles de detalle. En principio, la especificación de los requisitos funcionales de un sistema debe ser completa y consistente.
En sistemas grandes, es difícil de lograr debido a la gran cantidad de participantes, la facilidad para cometer errores en sistemas complejos, las diferentes necesidades, etc. Los problemas suelen surgir sólo después de un análisis en profundidad o después de que se entregó el sistema al cliente.
Son limitaciones sobre servicios o funciones que ofrece el sistema. Incluyen restricciones tanto de temporización y del proceso de desarrollo, como impuestas por los estándares. Los requisitos no funcionales se suelen aplicar al sistema como un todo, más que a características o a servicios individuales del sistema.
Son requisitos que no se relacionan directamente con los servicios específicos que el sistema entrega a sus usuarios. Pueden relacionarse con propiedades emergentes del sistema, como fiabilidad, tiempo de respuesta y uso de almacenamiento. De forma alternativa, pueden definir restricciones sobre la implementación del sistema, como las capacidades de los dispositivos I/O o las representaciones de datos usados en las interfaces con otros sistemas.
Especifican o restringen por lo general características del sistema como un todo.
Los requisitos no funcionales a menudo son más significativos que los requisitos funcionales individuales:
Los requisitos no funcionales surgen a través de necesidades del usuario, debido a restricciones presupuestales, políticas de la organización, necesidad de interoperabilidad con otro software o sistemas de hardware, o factores externos como regulaciones de seguridad o legislación sobre privacidad.
Los requisitos no funcionales provienen de características requeridas del software (requisitos del producto), la organización que desarrolla el software (requisitos de la organización) o de fuentes externas:
Siempre que sea posible, se deberán escribir de manera cuantitativa los requisitos no funcionales, de manera que puedan ponerse objetivamente a prueba usando métricas o unidades de medida.
De este modo, se puede verificar que los requisitos no funcionales se cumplan. Puede ser muy costoso. Este tipo de requisito puede interactuar e incluso entrar en conflicto con otros, de cualquier tipo.
Los requisitos del sistema no son independientes y no sólo detallan los servicios o las características que se requieren del mismo, sino también especifican la funcionalidad necesaria para asegurar que estos servicios y características se entreguen de manera adecuada.
Es un comunicado oficial de lo que deben implementar los desarrolladores del sistema. Incluye tanto los requisitos del usuario para un sistema, como una especificación detallada de los requisitos del sistema.
Son esenciales los documentos de requisitos cuando un contratista externo diseña el sistema de software. Sin embargo, los métodos de desarrollo ágiles argumentan que los requisitos cambian tan rápidamente que un documento de requisitos se vuelve obsoleto tan pronto como se escribe, así que el esfuerzo se desperdicia en gran medida. En lugar de un documento formal, los enfoques como la programación extrema recopilan de manera incremental requisitos del usuario y los escriben en tarjetas como historias de usuario.
Este enfoque es adecuado para sistemas empresariales donde los requisitos son inestables. Sin embargo, aún resulta útil escribir un breve documento de apoyo que defina los requisitos de la empresa y los requisitos de confiabilidad para el sistema; es fácil olvidar los requisitos que se aplican al sistema como un todo, cuando uno se enfoca en los requisitos funcionales para la siguiente liberación del sistema.
La diversidad de posibles usuarios significa que el documento de requisitos debe ser un compromiso entre la comunicación de los requisitos a los clientes, la definición de los requisitos con detalle preciso para desarrolladores y examinadores, y la inclusión de información sobre la posible evolución del sistema.
El nivel de detalle que se incluya en un documento de requisitos depende del tipo de sistema a diseñar y el proceso de desarrollo utilizado.
La especificación de requisitos es el proceso de escribir, en un documento de requisitos, los requisitos del usuario y del sistema. De manera ideal, los requisitos del usuario y del sistema deben ser claros, sin ambigüedades, fáciles de entender, completos y consistentes.
Los requisitos del usuario para un sistema deben describir los requisitos funcionales y no funcionales, de forma que sean comprensibles para los usuarios del sistema que no cuentan con un conocimiento técnico detallado. De manera ideal, deberían especificar sólo el comportamiento externo del sistema. El documento de requisitos no debe incluir detalles de la arquitectura o el diseño del sistema. En consecuencia, si usted escribe los requisitos del usuario, no tiene que usar jerga de software, anotaciones estructuradas o formales. Debe escribir los requisitos del usuario en lenguaje natural, con tablas y formas sencillas, así como diagramas intuitivos.
Idealmente, los requisitos del sistema deben describir de manera simple el comportamiento externo del sistema y sus restricciones operacionales. No tienen que ocuparse de cómo se diseña o implementa el sistema. Sin embargo, al nivel de detalle requerido para especificar por completo un sistema de software complejo, es prácticamente imposible excluir toda la información de diseño.
Los requisitos del usuario se escriben casi siempre en lenguaje natural, complementado con diagramas y tablas adecuados en el documento de requisitos. Los requisitos del sistema se escriben también en lenguaje natural, pero de igual modo se utilizan otras notaciones basadas en formas, modelos gráficos del sistema o modelos matemáticos del sistema.
Es expresivo, intuitivo y universal. También es potencialmente vago, ambiguo y su significado depende de los antecedentes del lector.
Para minimizar la interpretación errónea al escribir los requisitos en lenguaje natural, se recomienda:
3.2 Si se requiere, cada 10 minutos el sistema medirá el azúcar en la sangre y administrará insulina. (Los cambios de azúcar en la sangre son relativamente lentos, de manera que no son necesarias mediciones más frecuentes; la medición menos periódica podría conducir a niveles de azúcar innecesariamente elevados.)
3.6 Cada minuto, el sistema debe correr una rutina de autoevaluación, con las condiciones a probar y las acciones asociadas definidas en la tabla 1. (Una rutina de autoevaluación puede detectar problemas de hardware y software, y prevenir al usuario sobre el hecho de que la operación normal puede ser imposible.)
El lenguaje natural estructurado es una manera de escribir requisitos del sistema, donde está limitada la libertad del escritor de requisitos y todos éstos se anotan en una forma estándar.
Aunque este enfoque conserva la mayoría de la expresividad y comprensibilidad del lenguaje natural, asegura que haya cierta uniformidad sobre la especificación. Las anotaciones en lenguaje estructurado emplean plantillas para especificar requisitos del sistema. La especificación utiliza constructos de lenguaje de programación para mostrar alternativas e iteración, y destaca elementos clave con el uso de sombreado o de fuentes distintas.
Para usar un enfoque estructurado que especifique los requisitos de sistema, hay que definir una o más plantillas estándar para requisitos, y representar dichas plantillas como formas estructuradas. La especificación puede estructurarse sobre los objetos manipulados por el sistema, las funciones que el sistema realiza o los eventos procesados por el sistema.
Cuando se use una forma estándar para especificar requisitos funcionales, debe incluir la siguiente información:
Al usar especificaciones estructuradas se eliminan algunos de los problemas de la especificación en lenguaje natural. La variabilidad en la especificación se reduce y los requisitos se organizan de forma más efectiva. Sin embargo, en ocasiones todavía es difícil escribir requisitos sin ambigüedades, en particular cuando deben especificarse cálculos complejos.
Para enfrentar este problema se puede agregar información extra a los requisitos en lenguaje natural, por ejemplo, con el uso de tablas o modelos gráficos del sistema. Las tablas son particularmente útiles cuando hay algunas posibles situaciones alternas y se necesita describir las acciones a tomar en cada una de ellas.
Los procesos de ingeniería de requisitos incluyen cuatro actividades de alto nivel. Éstas se enfocan en valorar si el sistema es útil para la empresa (estudio de factibilidad), descubrir requisitos (adquisición y análisis), convertir dichos requisitos en alguna forma estándar (especificación) y comprobar que los requisitos definan realmente el sistema que quiere el cliente (validación).
Las actividades están organizadas como un proceso iterativo alrededor de una espiral, y la salida es un documento de requisitos del sistema. La cantidad de tiempo y esfuerzo dedicados a cada actividad en cada iteración depende de la etapa del proceso global y el tipo de sistema que está siendo desarrollado.
Un estudio de factibilidad es un breve estudio enfocado que debe realizarse con oportunidad en el proceso de IR.
Debe responder tres preguntas clave:
Si la respuesta a cualquiera de estas preguntas es negativa, probablemente no sea conveniente continuar con el proyecto.
En esta actividad, los ingenieros de software trabajan con clientes y usuarios finales del sistema para descubrir el dominio de aplicación, qué servicios debe proporcionar el sistema, el desempeño requerido de éste, las restricciones de hardware, etcétera.
Cada organización tendrá su versión o ejemplificación de este modelo general, dependiendo de factores locales, tales como experiencia del personal, tipo de sistema a desarrollar, estándares usados, etcétera.
Las actividades del proceso son:
Descubrimiento de requisitos:
Éste es el proceso de interactuar con los participantes del sistema para descubrir sus requisitos. También los requisitos de dominio de los participantes y la documentación se descubren durante esta actividad.
Clasificación y organización de requisitos:
Esta actividad toma la compilación no estructurada de requisitos, agrupa requisitos relacionados y los organiza en grupos coherentes. La forma más común de agrupar requisitos es usar un modelo de la arquitectura del sistema, para identificar subsistemas y asociar los requisitos con cada subsistema.
Priorización y negociación de requisitos:
Inevitablemente, cuando intervienen diversos participantes, los requisitos entrarán en conflicto. Esta actividad se preocupa por priorizar los requisitos, así como por encontrar y resolver conflictos de requisitos mediante la negociación.
Especificación de requisitos:
Los requisitos se documentan e ingresan en la siguiente ronda de la espiral. Pueden producirse documentos de requisitos formales o informales.
La adquisición y el análisis de requisitos es un proceso iterativo con retroalimentación continua de cada actividad a otras actividades.
El ciclo concluye cuando está completo el documento de requisitos. La adquisición y la comprensión de los requisitos por parte de los participantes del sistema es un proceso difícil por diferentes razones.
En la etapa de especificación de requisitos, los requisitos adquiridos hasta el momento se documentan de tal forma que puedan usarse para ayudar al hallazgo de requisitos. En esta etapa, podría generarse una primera versión del documento de requisitos del sistema, con secciones faltantes y requisitos incompletos.
El descubrimiento de requisitos (llamado a veces adquisición de requisitos) es el proceso de recopilar información sobre el sistema requerido y los sistemas existentes, así como de separar, a partir de esta información, los requisitos del usuario y del sistema.
Las fuentes de información durante la fase de descubrimiento de requisitos incluyen documentación, participantes del sistema y especificaciones de sistemas similares.
Los participantes varían desde administradores y usuarios finales de un sistema hasta participantes externos como los reguladores, quienes certifican la aceptabilidad del sistema
Además de los participantes del sistema, se observa que los requisitos también pueden venir del dominio de aplicación y de otros sistemas que interactúan con el sistema a especificar.
Un punto de vista es una forma de recopilar y organizar un conjunto de requisitos de un grupo de participantes que cuentan con algo en común. Por lo tanto, cada punto de vista incluye una serie de requisitos del sistema. Los puntos de vista pueden provenir de usuarios finales, administradores, etcétera.
Ayudan a identificar a los individuos que brindan información sobre sus requisitos y a estructurar los requisitos para análisis.
La manera más obvia de averiguar que necesitan los usuarios de un sistema de software es preguntarle a ellos. En estas entrevistas, el equipo de ingeniería de requisitos formula preguntas a los participantes sobre el sistema que actualmente usan y el sistema que se va a desarrollar. Los requisitos se derivan de las respuestas a dichas preguntas.
Las entrevistas son de dos tipos:
En la práctica, las entrevistas con los participantes son por lo general una combinación de ambas.
Las entrevistas no son tan útiles para comprender los requisitos desde el dominio de la aplicación.
Las entrevistas tampoco son una técnica efectiva para adquirir conocimiento sobre los requisitos y las restricciones de la organización, porque existen relaciones sutiles de poder entre los diferentes miembros en la organización.
Son costosas y dependen de las habilidades interpersonales de los involucrados.
Los entrevistadores efectivos poseen dos características:
La entrevista por sí misma está expuesta a perder información esencial y, por consiguiente, debe usarse junto con otras técnicas de adquisición de requisitos.
Por lo general, las personas encuentran más sencillo vincularse con ejemplos reales que con descripciones abstractas. Los escenarios son particularmente útiles para detallar un bosquejo de descripción de requisitos.
Durante el proceso de adquisición, se suman detalles a éste para crear una representación completa de dicha interacción.
Las historias que se usan en programación extrema, estudiadas en el capítulo 3, son un tipo de escenario de requisitos.
En su forma más general, un escenario puede incluir:
Los casos de uso son una técnica de descubrimiento de requisitos, identifica a los actores implicados en una interacción, y nombra el tipo de interacción. Entonces, esto se complementa con información adicional que describe la interacción con el sistema.
El conjunto de casos de uso representa todas las interacciones posibles que se describirán en los requisitos del sistema.
No hay distinción tajante y rápida entre escenarios y casos de uso.
Los escenarios y los casos de uso son técnicas efectivas para adquirir requisitos de los participantes que interactúan directamente con el sistema.
Cada tipo de interacción puede representarse como caso de uso. Sin embargo, debido a que se enfocan en interacciones con el sistema, no son tan efectivas para adquirir restricciones o requisitos empresariales y no funcionales de alto nivel, ni para descubrir requisitos de dominio.
Provee una representación de alto nivel de los requisitos de usuario.
Los sistemas de software no existen aislados. Se usan en un contexto social y organizacional, y dicho escenario podría derivar o restringir los requisitos del sistema de software.
La etnografía es una técnica de observación que se usa para entender los procesos operacionales y ayudar a derivar requisitos de apoyo para dichos procesos. Un analista se adentra en el ambiente laboral donde se usará el sistema. Observa el trabajo diario y toma notas acerca de las tareas existentes en que intervienen los participantes. El valor de la etnografía es que ayuda a descubrir requisitos implícitos del sistema que reflejan las formas en que trabaja la gente, en vez de los procesos formales definidos por la organización.
La etnografía es muy efectiva para descubrir dos tipos de requisitos:
No en todos los casos se identifican nuevas características que deben agregarse a un sistema. En consecuencia, la etnografía no es un enfoque completo para la adquisición por sí misma, y debe usarse para complementar otros enfoques, como el análisis de casos de uso.
Son una manera de estudiar a grandes grupos de usuarios para entender sus necesidades.
Su principal uso es para validar y obtener datos estadísticos sobre preferencias.
Preparar preguntas bien escritas es el mayor desafío.
Implica examinar los otros sistemas con los que se conecta el sistema.
Revela requisitos funcionales relativas al intercambio de datos y servicios entre sistemas.
Para cada sistema que se deba comunicar con el nuestro se identifican las funcionalidades que nos puedan generar requisitos. Esos requisitos pueden describir los datos a pasar a otros sistemas, los datos a recibir de otros sistemas y las reglas sobre los datos (por ejemplo criterios de validación).
Es útil para revisar las validaciones de la información a comunica o recibir (quizás, por ejemplo, se puedan omitir validaciones).
Implica estudiar sistemas existentes para determinar requisitos de usuario y funcionales.
Los mejor es utilizar sistemas existentes, pero sino se pueden utilizar screenshots (por ejemplo de manuales de usuario).
Puede ayudar a identificar una lista completa de pantallas y a descubrir características potenciales del nuevo sistema. Se utiliza para identificar pasos comunes de los usuarios al realizar tareas así como para crear borradores de casos de uso.
No hay que asumir que una funcionalidad es necesaria porque se encuentra en un sistema existente. O mantener la interfaz de usuario parecida o que se comporte de forma similar a la estudiada.
Contempla examinar toda la documentación existente en busca de requisitos potenciales del software.
La documentación más útil incluye especificación de requisitos, procesos de negocio, lecciones aprendidas y manuales de usuario de aplicaciones existentes o similares.
Es a una forma rápida de introducirse rápidamente en un nuevo dominio o en un sistema existente.
Ayuda a la participación de todos los involucrados.
Reglas: no se permite criticar ni debatir, generar tantas ideas como sea posible, mutar y combinar ideas.
El modelado del sistema es el proceso de desarrollar modelos abstractos del sistema, con cada modelo se presentan diferentes visiones o perspectivas.
Ayuda a los analistas a entender las funcionalidades del sistema y facilita la comunicación con los clientes.
En la actualidad es una actividad que se basa generalmente en la notación UML.
Los modelos de sistemas existentes se utilizan durante la ingeniería de requisitos. Ayudan a comprender qué hacen y pueden ser usados para discusiones acerca de sus fortalezas y debilidades.
Los modelos de nuevos sistemas son usados durante la ingeniería de requisitos para ayudar a explicar los requisitos propuestos a otros stakeholders del sistema. También para discutir propuestas de diseño y documentar el sistema para su implementación.
En un proceso de ingeniería guiado por modelos (model-driven), es posible generar de forma total o parcial una implementación del modelo del sistema.
Son usados para ilustrar el contexto operacional del sistema – muestran lo que está fuera de los límites del sistema.
Temas sociales y organizacionales pueden afectar la decisión sobre donde situar los límites del sistema.
Límites del Sistema: Definen qué está dentro y qué está fuera del sistema. La definición de los limites del sistema tiene un profundo efecto sobre los requisitos del sistema.
Podemos utilizar un diagrama de casos de uso que incluya la frontera del sistema como modelo de contexto.
Todo sistema involucra interacción: interacción con usuarios, con otros sistemas o entre sus componentes.
Modelar la interacción con los usuarios ayuda a identificar los requisitos de usuario.
Modelar la interacción con otros sistemas permite explorar posibles problemas de comunicación.
Modelar la interacción entre los componentes ayuda a entender sí la estructura propuesta del sistema es apropiada para los requisitos y atributos de calidad establecidos.
En UML podemos modelar la interacción de un sistema utilizando:
La validación de requisitos es el proceso de verificar que los requisitos definan realmente el sistema que en verdad quiere el cliente.
Durante el proceso de validación de requisitos, tienen que realizarse diferentes tipos de comprobaciones sobre los requisitos contenidos en el documento de requisitos:
Comprobaciones de validez
Un usuario quizá crea que necesita un sistema para realizar ciertas funciones. Sin embargo, con mayor consideración y análisis se logra identificar las funciones adicionales o diferentes que se requieran. Los sistemas tienen diversos participantes con diferentes necesidades, y cualquier conjunto de requisitos es inevitablemente un compromiso a través de la comunidad de participantes.
Comprobaciones de consistencia
Los requisitos en el documento no deben estar en conflicto. Esto es, no debe haber restricciones contradictorias o descripciones diferentes de la misma función del sistema.
Comprobaciones de totalidad
El documento de requisitos debe incluir requisitos que definan todas las funciones y las restricciones pretendidas por el usuario del sistema.
Comprobaciones de realismo
Al usar el conocimiento de la tecnología existente, los requisitos deben comprobarse para garantizar que en realidad pueden implementarse. Dichas comprobaciones también tienen que considerar el presupuesto y la fecha para el desarrollo del sistema.
Verificabilidad
Para reducir el potencial de disputas entre cliente y contratista, los requisitos del sistema deben escribirse siempre de manera que sean verificables. Esto significa que usted debe ser capaz de escribir un conjunto de pruebas que demuestren que el sistema entregado cumpla cada requisito especificado.
Hay algunas técnicas de validación de requisitos que se usan individualmente o en conjunto con otras:
Gestionar los cambios de los requisitos durante el proceso de ingeniería de requisitos y el desarrollo del sistema.
Nuevos requisitos surgen cuando un sistema está siendo desarrollado y después de haber entrado en uso.
Es necesario mantener un rastreo (trazabilidad) de los requisitos y mantener sus referencias para facilitar el análisis de impacto ante posibles cambios.
Se recomienda establecer un proceso formal de control de cambios.
El entorno empresarial y técnico del sistema siempre cambia después de la instalación. Nuevo hardware, nuevas interfaces con otros sistemas, cambian las prioridades del negocio, nuevas legislaciones, etc.
Las personas que pagan por un sistema y los usuarios de ese sistema casi nunca son las mismas personas.
Los grandes sistemas tienen una diversa comunidad de usuarios, algunos de los cuales tienen diferentes requisitos y pueden existir conflictos en las prioridades.
Establece el detalle del nivel de gestión requisitos que es requerido.
Decisiones de gestión de requisitos:
Es el proceso que se sigue en el análisis de requisitos de un cambio, e incluye las actividades que evalúan el impacto y costo del cambio.
Cuando un usuario propone un cambio de requisitos, este cambio no pasa por un proceso formal de gestión de cambios.
El usuario debe priorizar ese cambio y, si es de alta prioridad, debe decidir qué características del sistema que se planificaron para la próxima iteración se deben eliminar para que se implemente el cambio.
Pero…. en los sistemas con múltiples partes interesadas, los cambios beneficiarán a algunas partes interesadas y no a otras.
Sugerencia: autoridad independiente, que puede equilibrar las necesidades de todos los interesados